A block body contains also the classes that were added.
And a state diff contains also the contract roots, that is, the contracts that were deployed

After discussion with the team, it is true that both deployed_contract and replaced_classes can be derived from the optional StateDiff.ContractDiff.class_hash field as follows:

• If class_hash is present and the address is unknown then the contract has been deployed.
• If class_hash is present and the address is known then the contract's class has been replaced.

There is a possible edge case where a contract is deployed and replaced in the same block then an optional class_hash may not be sufficient for correctly deriving deployed_contracts and replaced_class. If the feeder StateDiff contains entries in both lists then calculating the StateDiff commitment would not be possible with the current message definition. However, this is an extremely rare scenario and @joshklop managed to create a block on Goerli where a contract was deployed and replaced in the same block. The resulting feeder StateDiff only modified the deployed_contracts therefore, this edge case is safe to ignore.

Verification of StateDiff commitment requires access to the latest state to create deployed_contracts and replaced_classes which can be slow to read from the DB. Therefore, a malicious peer can send incorrect StateDiff and an honest peer would not know about it until it loads the state from DB. If we add deployed_contracts and replaced_classes to StateDiff then StateDiff commitment verification becomes stateless.

@IronGauntlets , why would you need to get the deployed or replaced classes from the state diff? Verification of the state diff should be by executing the transactions. Maybe you are talking about making sure it is consistent with all other changes?

@ittaysw

why would you need to get the deployed or replaced classes from the state diff?

The signature over the state_diff_commitment includes deployed and replaced classes. Therefore, to verify the the received block and state diff from a peer we need to create the corresponding data over which the signature was created. As I mentioned above, it is possible to generate the data required if you have access to the state. However, it means that the signature cannot be verified until your state is at currentBlock - 1 which delays the verification of messages and possibly the sync process, also db access is slow.

Verification of the state diff should be by executing the transactions

AFAIU not all nodes would execute transactions and would rely on consensus signatures. Without the changes proposed in this PR verification of the signature is cumbersome for the reasons mentioned above.